User workstations, or clients, send request messages to CygNet services that are installed on servers. Only clients may initiate requests to services; services do not initiate requests to clients. Clients decide when information from a service is needed and only then do they initiate requests for information.
The method by which CygNet clients communicate with CygNet services is referred to as sessionless communications. This means that once a request is sent by a client and the associated response is received from the service, all resources associated with the connection are released and made available for other clients. Sessionless communication provides greater user accessibility, faster response times, more efficient bandwidth utilization, and less interruption to the overall CygNet system due to network error conditions.
All communications between CygNet clients and services involve one logical request message from a client followed by one logical response from a service. This exchange of messages is an autonomous operation that can be quickly and easily repeated if the client determines that it is necessary due to a data error or communication interruption.
Due to this sessionless communication model, there is no user logon to the CygNet system. A user launches CygNet client applications hosted by the Windows operating system environment. Once a user is logged on and authenticated to a Windows session, CygNet clients may be used to access server data. Client applications request data as needed, and once a response is received from the server, the transaction is complete. There is no logged on session maintained while a user operates within a client application. Multiple instances of CygNet client applications can be freely opened and closed, just like any other Windows application such as Microsoft Word, without logging on to a CygNet server. Each application instance will manage sending its own autonomous data requests in the model described above.
CygNet client requests check permissions for authenticated users to perform tasks in the software such as viewing data, changing configuration, or sending control commands. The service that administrates security is the Access Control Service (ACS). Each time a user attempts to perform a security event for any given application, a message is sent to the ACS to verify the user’s permission level. The permission levels are set for Windows user IDs and can be set up by system administrators. When the user’s permission level meets or exceeds the required permission level for the event, the ACS grants access via a verification message. When the user permission level is deficient or the event is not found in the ACS, access is denied.
Auditing in CygNet consists of recording changes made by users to services or records in a format that facilitates periodic review. Actions such as starting or stopping a service, updating or deleting a value in history, changing configuration records, and issuing a data poll command or setpoint can be audited. The Audit Service (AUD) is the service that stores the audit records. The level of detail contained in an audit record is configurable for each service. Auditing occurs on logical operations rather than individual CygNet messages because this level of recording would occur at too high a volume for efficient storage and retrieval. Rather, the aggregate operational changes to the system made by a user are stored for audit review.
The following diagram represents the client to server request and the server to client response.
|
|
|
